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Abstract 

High-level robot controllers in realistic domains typi- 
cally deal with processes which operate concurrently, 
change the world continuously, and where the execu- 
tion of actions is event-driven as in "charge the batter- 
ies as soon as the voltage level is low" . While non- logic- 
based robot control languages are well suited to express 
such scenarios, they fare poorly when it comes to pro- 
jecting, in a conspicuous way, how the world evolves 
when actions are executed. On the other hand, a logic- 
based control language like ConGolog, based on the sit- 
uation calculus, is well-suited for the latter. However, 
it has problems expressing event-driven behavior. In 
this paper, we show how these problems can be over- 
come by first extending the situation calculus to sup- 
port continuous change and event-driven behavior and 
then presenting cc-Golog, a variant of ConGolog which 
is based on the extended situation calculus. One ben- 
efit of cc-Golog is that it narrows the gap in expres- 
siveness compared to non-logic-based control languages 
while preserving a semantically well-founded projection 
mechanism. 

Introduction 

High-level robot controllers typically specify processes 
which operate concurrently and change the world in 
a continuous fashion over time. Several special pro- 
gramming languages such as RPL (McDermott 1992), 1 
rap (Firby 1987), or COLBERT (Konolige 1997) have 
been developed for this purpose. As an example, con- 
sider the following RPL-program: 

WITH-POLICY WHENEVER Batt- Level < 46 
CHARGE-BATTERIES 
WITH-POLICY WHENEVER NEAR-DOOR(RmA-118) 
SAY( "hello") 

DELIVER-MAIL 

Figure 1: Office delivery plan 

Roughly, the robot's main task is to deliver mail, 
which we merely indicate by a call to the proce- 
dure deliver-mail. While executing this procedure, the 

1 rpl has recently been used successfully to control the 
behavior of a mobile robot deployed in a realistic environ- 
ment for an extended period of time (Thrun et al. 1999). 



robot concurrently also does the following, with an in- 
creasing level of priority: whenever it passes the door 
to Room A- 118 it says "hello" and, should the battery 
level drop dangerously low, it recharges its batteries in- 
terrupting whatever else it is doing at this moment. 

Even this simple program exhibits important features 
of high-level robot controllers: (1) The timing of ac- 
tions is largely event-driven, that is, rather than ex- 
plicitly stating when an action occurs, the execution 
time depends on certain conditions becoming true such 
as reaching a certain door. Most robot control lan- 
guages realize this feature using the special construct 
waitFor(4>) , which suspends activity until <f> becomes 
true. 2 (2) Actions are executed as soon as possible. For 
example, the batteries are charged immediately after 
a low voltage level is determined. (3) Conditions such 
as the voltage level are best thought of as changing 
continuously over time. (4) Parts of programs which 
execute concurrently and with high priority must be 
non-blocking. For example, while waiting for a low bat- 
tery level, mail delivery should continue. On the other 
hand, the actual charging of the battery should block 
all other activity. 

Given the inherent complexity of concurrent robot 
programs, answers to questions like whether a program 
is executable and whether it will satisfy the intended 
goals are not easy to come by, yet important to both 
the designer during program development and the robot 
who may want to choose among different courses of ac- 
tion. A principled approach to answering such ques- 
tions is to project how the world evolves when actions 
are performed, a method which also lies at the heart of 
planning. 

In the case of RPL, a projection mechanism called 
XFRM exists (McDermott 1992; 1994), but it has prob- 
lems. 3 Perhaps the most serious deficiency of XFRM is 
that projections rely on using RPL's execution mecha- 
nism, which lacks a formal semantics and which makes 



2 In the example, waitFor is hidden within the whenever- 
construct. 

3 As far as we know, other non-logic-based robot control 
languages like RAP or COLBERT do not even consider projec- 
tion. 



predictions implementation dependent. Preferably one 
would like a language which is as powerful as RPL yet al- 
lows for projections based on a perspicuous, declarative 
semantics. 

The recently proposed language ConGolog (de Gia- 
como, Lesperance, & Levesque 1997) fulfills some of 
these desiderata as it offers many of the features of RPL 
such as concurrency, priorities etc. and, at the same 
time, supports rigorous projections of plans 4 because 
it is entirely based on the situation calculus (McCarthy 
1963; Levesque, Pirri, & Reiter 1998). 

It turns out, however, that despite many similari- 
ties, ConGolog in its current form is not suitable to 
represent robot controllers such as the example above. 
The main problem is that the existing temporal ex- 
tensions of the situation calculus such as (Pinto 1997; 
Reiter 1996) require that the execution time of an ac- 
tion is supplied explicitly, which seems incompatible 
with event-driven specifications. To solve this prob- 
lem we proceed in two steps. First we present a new 
extension of the situation calculus which, besides deal- 
ing with continuous change, allows us to model actions 
which are event-driven by including waitFor as a spe- 
cial action in the logic. We then turn to a new variant 
of ConGolog called cc-Golog, which is based on the ex- 
tended situation calculus. We study issues arising from 
the interaction of waitFbr-actions and concurrency and 
show how the example-program can be specified quite 
naturally in cc-Golog with the additional benefit of sup- 
porting projections firmly grounded in logic. 

The rest of the paper is organized as follows. In the 
next section, we briefly review the basic situation cal- 
culus. Then we show how to extend it to include con- 
tinuous change and time. After a very brief summary 
of ConGolog, we present cc-Golog, which takes into ac- 
count the extended situation calculus. This is followed 
by a note on experimental results and conclusions. 

The Situation Calculus 

One increasingly popular language for representing and 
reasoning about the preconditions and effects of actions 
is the situation calculus (McCarthy 1963). We will not 
go over the language in detail except to note the follow- 
ing features: all terms in the language are one of three 
sorts, ordinary objects, actions or situations; there is 
a special constant So used to denote the initial situa- 
tion, namely that situation in which no actions have yet 
occurred; there is a distinguished binary function sym- 
bol do where do(a, s) denotes the successor situation 
to s resulting from performing the action a; relations 
whose truth values vary from situation to situation are 
called relational fluents, and are denoted by predicate 
symbols taking a situation term as their last argument; 
similarly, functions varying across situations are called 

4 In this paper we will use the terms program and plan 
interchangeably, following McDermott (McDermott 1992) 
who takes plans to be programs whose execution can be 
reasoned about by the agent who executes the program. 



functional fluents and are denoted analogously; finally, 
there is a special predicate Poss(a, s) used to state that 
action a is executable in situation s. 

Within this language, we can formulate theories 
which describe how the world changes as the result of 
the available actions. One possibility is a basic action 
theory of the following form (Levesque, Pirri, & Reiter 
1998): 

• Axioms describing the initial situation, So- 

• Action precondition axioms, one for each primitive 
action a, characterizing Poss(a,s). 

• Successor state axioms, one for each fluent F, stat- 
ing under what conditions F(x, do(a, s)) holds as a 
function of what holds in situation s. These take the 
place of the so-called effect axioms, but also provide 
a solution to the frame problem (Levesque, Pirri, & 
Reiter 1998). 

• Domain closure and unique name axioms for the ac- 
tions. 

• Foundational, domain independent ax- 
ioms (Levesque, Pirri, & Reiter 1998). 

1. VP.P(5o) A [VsVa.(P(s) D P(do(a,s)))} D VsP(s); 

2. do(a, s) = do(a', s') D a = a' A s = s'; 5 

3. -.(s C S ); 

4. s □ do(a,s') = s C s' , where s C s' stands for 
(s C s') V (s = s'). 

5. s -< s' = s C s' A Va, s*.s C do(a,s*) C s' D 
Poss(a, s*) 

The first is a second-order induction axiom ensuring 
that the only situations are those obtained from apply- 
ing do to So- The second is a unique names axiom for 
situations. C defines an ordering relation over situa- 
tions. Intuitively, s C s' holds if s' can be obtained 
from s by performing a finite number of actions. Fi- 
nally, s ~< s' holds when there is a legal sequence of 
actions leading from s to s', where legal means that 
each action is possible. 

Continuous Change and Time 

Actions in the situation calculus cause discrete changes 
and, in its basic form, there is no notion of time. In 
robotics applications, however, we are faced with pro- 
cesses such as navigation which cause properties like the 
robot's location and orientation to change continuously 
over time. In order to model such processes in the situa- 
tion calculus in a natural way, we add continous change 
and time directly to its ontology. 

As demonstrated by Pinto and Reiter (Pinto 1997; 
Reiter 1996), adding time is a simple matter. We add 
a new sort real ranging over the real numbers and, for 
mnemonic reasons, another sort time ranging over the 

5 We use the convention that all free variables are implic- 
itly universally quantified. 



reals as well. 6 In order to connect situations and time, 
we add a special unary functional fluent start to the 
language with the understanding that start(s) denotes 
the time when situation s begins. We will see later 
how start obtains its values and, in particular, how the 
passage of time is modeled. 

A fundamental assumption of the situation calculus 
is that fluents have a fixed value at every given situa- 
tion. In order to see that this assumption still allows us 
to model continuous change, let us consider the exam- 
ple of a mobile robot moving along a straight line in a 
1-dimensional world, that is, the robot's location at any 
given time is simply a real number. There are two types 
of actions the robot can perform, start Go(v), which ini- 
tiates moving the robot with speed v, and endGo which 
stops the movement of the robot. Let us denote the 
robot's location by the fluent robotLoc. What should 
the value of robotLoc be after executing startGo(v) in 
situation s? Certainly it cannot be a fixed real value, 
since the position should change over time as long as the 
robot moves. In fact, the location of the robot at any 
time after startGo(v) (and before the robot changes its 
velocity) can be characterized (in a somewhat idealized 
fashion) by the function i + ux (t — to), where x is the 
starting position and to the starting time. The solution 
is then to take this function of time to be the value of 
robotLoc. We call functional fluents whose values are 
continuous functions continuous fluents. 

The idea of continuous fluents, which are often called 
parameters, is not new. Sandewall (Sandewall 1989) 
proposed it when integrating the differential equations 
into logic, Galton (Galton 1990) investigated similar 
issues within a temporal logic, and Shanahan consid- 
ers continuous change in the event calculus (Shana- 
han 1990). Finally, Miller and Pinto (Miller 1996; 
Pinto 1997) formulate continuous change in the situ- 
ation calculus. Here we essentially follow Pinto, in a 
somewhat simplified form. 

We begin by introducing a new sort t-function, whose 
elements are meant to be functions of time. We as- 
sume that there are only finitely many function symbols 
of type t-function and wc require domain closure and 
unique names axioms for them, just as in the case of 
primitive actions. For our robot example, it suffices to 
consider two kinds of t-functions: constant functions, 
denoted by constant{x) and the special linear functions 
introduced above, which we denote as linear(x, v, to)- 

Next we need to say what values these functions have 
at any particular time t. We do this with the help of a 
new binary function vol. In the example, we would add 
the following axioms: 

val(constant(x),t) — x; 

val(linear(x, v, t ), t) = x + v x (t — to)- 

Let us now turn to the issue of modeling the pas- 
sage of time during a course of actions. As indicated in 

6 For simplicity, the reals are not axiomatized and we as- 
sume their standard interpretations together with the usual 
operations and ordering relations. 



the introduction, motivated by the treatment of time in 
robot control languages like rpl, rap, or Colbert, we 
introduce a new type of primitive action waitFor((f>) . 
The intuituion is as follows. Normally, every action 
happens immediately, that is, the starting time of the 
situation after doing a in s is the same as the starting 
time of s. The only exception is waitFor(4>): whenever 
this action occurs, the starting time of the resulting 
situation is advanced to the earliest time in the future 
when <f) becomes true. Note that this has the effect 
that actions always happen as soon as possible. One 
may object that requiring that two actions other than 
waitFor must happen at the same time is unrealistic. 
However, in robotics applications, actions often involve 
little more than sending messages in order to initiate or 
terminate processes so that the actual duration of such 
actions is negligible. Moreover, if two actions cannot 
happen at the same time, they can always be separated 
explicitly using waitFor. 

For the purposes of this paper, we restrict the argu- 
ment of waitFor to what we call a t-form, which is a 
Boolean combination of closed atomic formulas of the 
form (F op r), where F is a continuous fluent with the 
situation argument suppressed, op G {<,=}, 7 and r is 
a term of type real (not mentioning vat). An example 
is (f> — (robotLoc > 1000). To evaluate a t-form at a 
situation s and time t, we write </>[s,£] which results 
in a formula which is like <p except that every contin- 
uous fluent F is replaced by val(F(s),t). For instance, 
(robotLoc > 1000) [s,t] becomes (val(robotLoc(s),t) > 
1000). For reasons of space we completely gloss over 
the details of reifying t-forms within the language 8 ex- 
cept to note that we introduce t-forms as a new sort 
and that 4>[s,t] is short for Holds(<p, s,t), where Holds 
is appropriately axiomatized. 

To see how actions are forced to happen as soon as 
possible, let ltp(4>,s,t) be an abbreviation for the for- 
mula 

<j>[s,t]At > start(s) A\ft' .start(s) <t' <tD ^<j)[s,t'], 
that is, t in ltp(<fr, s, t) is the least time point after the 
start of s where 4> becomes true. 9 

Then we require that a waitFor-action is possible iff 
the condition has a least time point: 

Poss(waitFor(<j)), s) = 3t.ltp((f>, s,t). 

It is not hard to show that, if 3t.ltp((f), s,t) is satis- 
fied, then t is unique. Finally, we need to characterize 
how the fluent start changes its value when an action 
occurs. The following successor state axiom for start 
captures the intuituion that the starting time of a situ- 
ation changes only as a result of a waitFor(<j)) , in which 

7 We freely use <, >, or > as well. 

8 See, for example, (Giacomo, Lesperance, & Levesque 
1999) for details how this can be done. 

9 This is not unlike Reiter's definition of a least nat- 
ural time point in the context of natural actions (Reiter 
1996). Similar ideas occur in the context of delaying pro- 
cesses in real-time programming languages like Ada (Burns 
& Wellings 1991). 



case it advances to the earliest time in the future when 
(f> holds. 

Poss(a, s) D [start(do(a, s)) = t = 
3(j).a = waitFor(4>) A ltp((j), s, t)V 
[\/(f>.a waitFor{(j)) At = start(s)]]. 

Let AX be the set of foundational axioms of the previ- 
ous section together with the domain closure and unique 
names axioms for t-functions, the axioms required for 
t-form's, the precondition axiom for waitFor, and the 
successor state axiom for start. Then the following for- 
mulas are logical consequences of AX. 

Proposition 1: 

1. The starting time of legal action sequences is mono- 
tonically nondecr easing: 

Vs, s'.s ~< s' D start(s) < start(s'). 

2. Actions happen as soon as possible: 
[Va,s.start(do(a,s)) = start(s)] V [3(f). a = 
waitFor((p) A ltp{4>, s, start(do(a, s)))] 

To illustrate the approach, let us go back to the robot 
example. First, we can formulate a successor state ax- 
iom for robotLoc: 

Poss(a,s) D [robotLoc(do(a, s)) = y = 

3to, v,x.x = val(robotLoc(s),to) A to = starts) A 
[a = startGo(v) Ay — linear(x, v, t ) 

Va = endGo Ay = constant(x) V y = robotLoc(s)A 

->3v.(a = startGo(v) V a = endGo)]] 

In other words, when an action is performed robotLoc 
is assigned either the function linear(x, v,t ), if the 
robot starts moving with velocity v and x is the location 
of the robot at situation s, or it is assigned constant(x) 
if the robot stops, or it remains the same as in s. 10 

Let S be AX together with the axioms for vol, 
the successor state axiom for robotLoc, precondition 
axioms stating that startGo and endGo are always 
possible, and the fact (robotLoc(So) = constant(0)) , 
that is, the robot initially rests at position 0. Let 
us assume the robot starts moving at speed 50 
(cm/s) and then waits until it reaches location 1000 
(cm), at which point it stops. The resulting sit- 
uation is si = do(endGo, do(waitFor(robotLoc = 
1000) , do(startGo(50) , S Q ) ) ) . Then 

E |= start(si) = 20 A robotLoc(si) = constant(1000) . 

In other words, the robot moves for 20 seconds and 
stops at location 1000, as one would expect. 

In summary, to model continuous change and time 
in the situation calculus, we have added four new sorts: 
real, time, t-function (functions of time), and t-form 
(temporal formulas). In addition, we introduced a spe- 
cial function val to evaluate t-functions, a new kind 
of primitive action waitFor together with a domain- 
independent precondition axiom, and a new fluent start 
(the starting time of a situation) together with a suc- 
cessor state axiom. 



10 Note that val(robotLoc(s) , to) is well-defined since every 
t-function has a name (constant or linear) with correspond- 
ing axioms for val as given above. 



ConGolog 

ConGolog (Giacomo, Lesperance, & Levesque 1999), an 
extension of GOLOG (Levesque et al. 1997), is a for- 
malism for specifying complex actions and how these 
are mapped to sequences of atomic actions assuming 
a description of the initial state of the world, action 
precondition axioms and successor state axioms for 
each fluent. Complex actions are defined using control 
structures familiar from conventional programming lan- 
guage such as sequence, while-loops and recursive pro- 
cedures. In addition, parallel actions arc introduced 
with a conventional interleaving semantics. Here we 
confine ourselves to the deterministic fragment of Con- 
Golog. (While nondeterministic actions raise interesting 
issues, we ignore them for reasons of space. Also note 
that nondeterminism plays little if any role in languages 
like RPL.) 

a primitive action 

4>1 test action 11 

seq(ai, 02) sequence 
if(4>, 0-1,0-2) conditional 
while((f>, a) loop 
par (o~\, o~2 ) concurrent execution 
prio(p\ , <T2 ) prioritized execution 
proc {3(x)a procedure definition 

The semantics of ConGolog is defined using the so- 
called transition semantics, which defines single steps 
of computation. There is a relation, denoted by the 
predicate Trans(a, s, 5, s'), that associates with a given 
program a and situation s a new situation s' that results 
from executing a primitive action in s, and a new pro- 
gram S that represents what remains of a after having 
performed that action. Furthermore, we need to de- 
fine which configurations (7, s) arc final, meaning that 
the computation can be considered completed when a 
final configuration is reached. This is denoted by the 
predicate Final (a, s). 12 . 

We do not consider the axiomatization concerning 
the proc instruction, which is more subtle to handle. 13 
Note that the semantics is defined for the non-temporal 
situation calculus. Adapting the semantics to the tem- 
poral situation calculus of the previous section will be 
the subject of the next section. 

Final(a, s) = false , where a is a primitive action 

Final(nil, s) = true, where nil is the empty program 

Final(4>l, s) = false 

11 Here, <f> stands for a situation calculus formula 
with all situation arguments suppressed, for example 
hasMail(gerhard). <j>[s] will denote the formula obtained 
by restoring situation variable s to all fluents appearing in 
</>. 

12 Again, we gloss over the issue of reifying formulas and 
programs in the logical language and refer to (Giacomo, 
Lesperance, & Levesque 1999) for details. 

13 Indeed, it necessitates a second order axiomatization 
of Trans; see (Giacomo, Lesperance, & Levesque 1999) for 
details. 



Final (seq(a\, 02), s) = Final(a\,s) A Final{o2, s) 

Final(if{4>, o~\, 02), s) = 

</>[s] A Final(p\, s) V ^</>[s] A Final{o2, s) 

Final (while(4>, a), s) = ^</>[s] V Final(a, s) 

Final(par(a\, a 2 ), s) = Final(a\,s) A Final{o2, s) 

Final(prio(a\, a 2 ), s) = Final{o\, s) A Final(o-2, s) 

Trans(a, s, S, s') = 

Poss(a, s) AS — nil A s' = do(a, s) 

Trans(nil, s, 5, s') = false 

Trans(<fi7, s, 5, s') = <fi[s] A 5 = nil A s' = s 

Trans(seq(ai, a 2 ), s, S, s') = 

Final(ai,s) A Trans(<j2, s, S, s')V 
35'.Trans(ai,s, 5', s') A S = seq(S' , a 2 ) 

Trans(if(4>, a\, ct 2 ), s, 8, s') = 
<p[s] A Trans{o~\, s, 5, s')V 
-<<f)[s] A Trans(a2, s, 5, s') 

Trans(while(4>, a), s, (5, s') = 

3j.5 = seq(j, while{<p, a)) A </>[s]A 
Trans{a 1 s, 7, s') 

Trans(par(<Ji,<j2),s,5,s') = 

3j.5 = par(7, cr 2 ) A Trans(a\, s, 7, s')V 
37. (5 = par(ai, 7) A Trans(<j2, s, 7, s') 

Trans(prio(ai, (T 2 ) , s, <5, s') = 

37.5 = prio(j, 02) A Trans(ai,s, 7, s')V 
37.5 = prio(ai, 7) A Trans{a2, s, 7, s')A 
^'^".Trans^i.s^'^") 

Intuitively, a program cannot be in its final state if 
there is still a primitive action to be done. Similarly, 
a concurrent execution of two programs is in its final 
state if both are. As for Trans, let us just look at par: 
a transition of two programs working in parallel means 
that one action of one of the programs is performed. 

A final situation s' reachable after a finite number of 
transitions from a starting situation is identified with 
the situation resulting from a possible execution trace 
of program a, starting in situation s; this is captured 
by the predicate Do(a, s, s'), which is defined in terms 
of Trans*, the transitive closure of Trans: 

Do(5, s, s') = 3S'.Trans*(5, s, 6', s') A Final(S', s') 
Trans*(S, s, 6', s') = VT[... D T(S, s, 5', s')] 

where the ellipsis stands for the conjuction of the 
following formulas: 

T(S,s,S,s) 

Trans(S, s, 6", s") A T(S", s", 5', s') D T(S, s, 5', a') 

Given a program S, proving that S is executable 
in the initial situation then amounts to proving £ |= 
3sDo(S, So, s), where S consists of the above axioms 
for ConGolog together with a basic action theory in the 
situation calculus. 



cc-Golog: a Continuous, Concurrent 
Golog 

Let us now turn to cc-Golog, which is a variant of de- 
terministic ConGolog and which is founded on our new 
extension of the situation calculus. 

First, for reasons discussed below we slightly change 
the language by replacing the instructions par and prio 
by the constructs try All and withPol, respectively. In- 
tuitively, try All {a 1, 02) starts executing both a\ and 
(T2 ; but unlike par, which requires both <j\ and cr 2 to 
reach a final state, the parallel execution of try All stops 
as soon as one of them reaches a final state. As for 
withPol{a\, 02 ), the idea is that a low priority plan 02 
is executed, which is interrupted whenever the program 
a\, which is called a policy, is able to execute. The ex- 
ecution of the whole withPol construct ends as soon 
as 2 ends. (Note that prio is just like withPol except 
that for prio to end both o\ and ct 2 need to have ended.) 

tryAll and withPol are inspired by similar instruc- 
tions in rpl where they have been found very useful 
in specifying complex concurrent behavior. In particu- 
lar, withPol is useful to specify the execution of a plan 
while guarding certain constraints. As we will see later, 
it is quite straightforward to define par and prio us- 
ing the new instructions. On the other hand, defining 
tryAll and withPol in terms of par and prio appears 
to be more complicated. Hence we decided to trade par 
and prio for their siblings. 

Let us now turn to the semantics of cc-Golog, which 
means finding appropriate definitions for Final and 
Trans. To start with, the semantics remains exactly 
the same for all those constructs inherited from deter- 
ministic ConGolog. Note that this is also true for the 
new waitFor((j)) , which is treated like any other primi- 
tive action. 14 Hence we are left to deal with tryAll and 
withPol. 

It is straightforward to give Final its intended 
meaning, that is, tryAll ends if one of the two pro- 
grams ends and withPol ends if the second program 
ends: 

Final(tryAll(ai, 02, s)) = Final{a\, s)VFinal(a2, s) 
Final(withPol(ai,o~ 2 ), s) = Final(o~2,s) 
When considering the transition of concurrent pro- 
grams, care must be taken in order to avoid conflicts 
with the assumption that actions should happen as soon 
as possible, which underlies our new version of the situ- 
ation calculus. To see why let us consider the following 
example, where we want to instruct our robot to run a 
backup at time 8 or 20, whichever comes first. Let us 
assume we have a continuous fluent clock representing 
the time 15 and let runBackup be always possible. Given 



The reader familiar with ConGolog may wonder whether 
a test action 0? is the same as waitFor(<f>) . This is not so. 
Roughly, the main difference is that tests have no effect on 
the world while waitFor advances the time. 

15 This can be modeled using a simple linear function, but 
we ignore the details here. 



our intuitive reading of try All, we may want to use the 
following program: 

seq(tryAll(waitFor(clock — 8), waitFor(clock = 20)), 
runBackup) 

If we start the program at time we would expect to 
see 

[waitFor( clock=8), runBackup] 

as the only execution trace, since time 8 is reached 
first. (Recall that tryAll finishes as soon as one of its 
arguments finishes.) However, this is not necessarily 
guaranteed. In fact, the obvious adaptation of Con- 
Golog's Trans-definition of par to the case of tryAll 16 
also yields the trace 

[waitFor( clock=20) , runBackup] . 

This is because there simply is no preference enforced 
between the two waiiFor-actions. As the following defi- 
nition shows, it is not hard to require that actions which 
can be executed earlier are always preferred, restoring 
the original idea that actions should happen as early as 
possible. 

Trans(tryAll(a\, 0-2), s, 5, s') = 
-^Final(a\, s) A ~^Final(a 2 , s)A 

3S\.Trans(ai,s, 5\, s') A S = try All (6 1, 02) A 

s 2 .Trans(o 2 , s, S 2 , s 2 ) D start(s') < start(s2)] 
V 3d 2 .Trans(a 2 , s, 5 2 , s') A 5 = tryAll(a 1 ,S 2 )A 
V#i, si.Trans(ai, s, Si, si) D start(s') < start(si)] 

We are left with defining Trans for withPol. To see 
what is involved, let us consider the following example 

withPol(watchB , deliver Mail), where 

watchB — seq(waitFor(battLevel < AQ),chargeBatf). 
The idea is to deliver mail and, with higher priority, 
watch for a low battery level, at which point the bat- 
teries are charged. In the discussion of a similar sce- 
nario written in RPL, we already pointed out that the 
waitFbr-action should not block the mail delivery even 
though it belongs to the high priority policy. On the 
other hand, once the routine for charging the batteries 
starts, it should not be interrupted, that is, it should 
run in blocking mode, which should also hold for possi- 
ble waitFbr-actions it may contain such as waiting for 
arrival at the docking station. It turns out that it suf- 
fices to arrange in the semantics of Trans that occur- 
rences of waitFor within a policy are considered non- 
blocking. As we will see below, the effect of a policy 
running in blocking mode is definable by other means. 

Interestingly, the resulting axiom is almost identical 
to that of tryAll: the main difference is that < is re- 
placed by < in the last line. This ensures that o\ takes 
precedence if both tJj are about to execute an action at 
the same time. 



16 Roughly, replace par by tryAll and add ->Final(oi, s) 
and -^Final{<J2, s) as additional conjuncts on the definition's 
R.H.S. 



Trans(withPol(o\, a 2 ), s, 5, s') = -^Final(a 2 , s)A 
35i.Trans(ai,s, 5\, s') A 5 = withPol(5\, ct 2 )A 
\/8 2 ,s 2 .Trans((j 2 ,s,5 2 ,s 2 ) D start(s') < start(s 2 )] 
V 3d 2 . Trans (o~ 2 , s, 5 2 , s') A S = withPol(o\, 5 2 )A 
\fS\, S\.Trans(o\, s,S\, si) D start(s') < start(s\)] 

This then ends the discussion of the semantics of 
Trans in cc-Golog. Trans* and Do(5, s, s') are defined 
the same way as in ConGolog. 

One issue left open is to show how a policy can run in 
blocking mode. This can be arranged using the macro 
withCtrl{4>, a), which stands for a with every primitive 
action or test a replaced by if((j>, a, false?). 17 

Intuitively withCtrl{<j),a) executes a as long as <fi is 
true, but gets blocked otherwise. As the following ex- 
ample shows, the effect of a policy in blocking mode is 
obtained by having the truth value of <j) be controlled 
by the policy and using the withCtrl{4>, (reconstruct in 
the low priority program. 

This leads us, finally, to the specification of our 
initial example in cc-Golog. In the following we 
assume a fluent wheels, which is initially true, 
set false by grabWhls, and reset by the action 
releaseWhls. We also use whenever((j>, a) as short- 
hand for while(true, seq{waitF or{4>) , a)). 



withPol(whenever(battLevel < 46, 

seq(grabWhls, chargeBatteries, releaseW hls) ls ) , 
withPol(whenever (near Door A-118, 

seq(say(hello) , waitFor(-^near Door A-118))) 
withCtrliwheels, deliver Mail))) 



Figure 2: The introductory example as cc-Golog plan. 

In this program, the outermost policy is waiting un- 
til the battery level drops to 46. At this point, a 
grabWheels is immediately executed, which blocks the 
execution of the program deliver Mail. It is only after 
the complete execution of chargeBatteries that wheels 
gets released so that deliver Mail may resume execution 
(if, while driving to the batterie docking station, the 
robot passes by RmA — 118, it would still say "hello"). 

Note that the cc-Golog-program is in a form very close 
to the original RPL-program we started out with. Hence 
we feel that cc-Golog is a step in the right direction 
towards modeling more realistic domains which so far 
could only be dealt with in non-logic-based approaches. 
Moreover, with their rigorous logical foundation, it is 
now possible to make provable predictions about how 
the world evolves when executing cc-Golog-programs. 
(See also the next section on experimental results.) 

17 Wc remark that if ((f), a, false?) can only lead to a tran- 
sition if cj> is true in the current situation at which point 
a is executed immediately. This is essentially due to the 
fact that false? is neither Final nor can it ever lead to a 
transition (see (Giacomo, Lesperance, & Levesque 1999)). 

19 seq(a\, 02,03) is a shorthand for seq(oi, seq(o2, 03)). 
We will also use a similar shorthand for tryAll. 



Finally, let us briefly consider how par and prio 
which we dropped in favor of tryAll and withPol 
arc definable within cc-Golog. Let us assume fluents 
flgi which are initially false and set true by setFlgi. 
Then we can achieve what amounts to par(<7i, 02) by 
tryAll{seq{a 1 ,setFlgl, flg2?), seq{a 2 , setFlg2, flglT)). 
Note that the testing of the flags at the end 
of each program forces that both o~i need 
to finish. Similarly, prio can be defined as 
withPol(seq(ai, setFlg), seq(<72, 

We end this section with some remarks on Re- 
iter's proposal for a temporal version of GOLOG (Re- 
iter 1998), 19 which makes use of a different tempo- 
ral extension of the situation calculus (Pinto 1997; 
Reiter 1996). Roughly, the idea is that every primi- 
tive action has as an extra argument its execution time. 
E.g., we would write endGo(20) to indicate that endGo 
is executed at time 20. It turns out that this explicit 
mention of time is highly problematic when it comes 
to formulating programs such as the above. Consider 
the part about saying "hello" whenever the robot is 
near Room A-118. In Reitcr's approach, the program- 
mer would have to supply a temporal expression as an 
argument of the say-action. However, it is far from 
obvious what this expression would look like since it in- 
volves analyzing the mail delivery subprogram as well 
as considering the odd chance of a battery recharge. In 
a nutshell, while Reiter's approach forces the user to 
figure out when to act, we let cc-Golog do the work. 
— As a final aside, we remark that waitFor-actions al- 
low us to easily emulate Reiter's approach within our 
framework. 

Experimental Results 

Although the definition of cc-Golog requires second- 
order logic, it is easy to implement a PROLOG in- 
terpreter for cc-Golog, just as in the case of the orig- 
inal ConGolog. 20 In order to deal with the constraints 
implied by the waitFor instruction, we have made 
use of the ECRC Common Logic Programming Sys- 
tem Eclipse 4.2 and its built-in constraint solver library 
clpr to implement a cc-Golog interpreter (similar to 
Reiter (Reiter 1998)). 

We used three example plans to compare the per- 
formance of our cc-Golog interpreter with earlier work 
on the projection of continuous change (Bcctz & 
Grosskreutz 1998) within the xfrm (McDermott 1992; 
1994) framework. As an example environment, we use 
the one of (Beetz & Grosskreutz 1998), depicted in Fig- 
ure 3. We approximated the robot's trajectory by poly- 
lines, consisting of the starting location, the goal loca- 
tion and a point in front of and behind every passed 
doorway (similar to (Beetz & Grosskreutz 1998)): 

19 While the paper is about sequential GOLOG, the exten- 
sion to ConGolog is straightforward. 

20 The subtle differences between the second order axiom- 
atization of ConGolog and a PROLOG implementation are 
discussed in (Giacomo, Lesperance, & Levesque 1999). 




Figure 3: The robot environment 

• The introductory example (Fig. 2). We assumed that 
there are two letters to be delivered and that the 
delivery is once interrupted by low battery voltage. 

• The (slightly modified) example of (Beetz & 
Grosskreutz 1998). Again, the robot is to deliver let- 
ters. But at the same time, it has to monitor the state 
of the environment, that is it has to check wether 
doors are open. As soon as it realizes that the door 
to A-113 is open, it has to interrupt its actual de- 
livery in order to deliver an urgent letter to A-113. 
This is specified as a policy that leads the robot in- 
side A-113 as soon as the opportunity is recognizes. 
Note that in the implementation, we used PROLOG 
lists ( [al , a2 , . . . ] ) instead of seq{a\, a%, ...). 

withPol (whenever ( inHallway , 
[say (enterHW) , 
tryAlK [whenever (nearDoor (a-110) , 

[checkDoor(a-110+121) .false?])] , 
[whenever (nearDoor (a-111) , 

[checkDoor(a-lll+120) .false?])] , 
[whenever (nearDoor (a-112) , 

[checkDoor(a-112+119) .false?])] , 
[whenever (nearDoor (a-113) , 

[checkDoor(a-113+118) .false?])] , 
[whenever (nearDoor (a-114) , 

[checkDoor(a-114+117) .false?])] , 
[waitFor (leftHallway) , 
say(leftHW)])]), 
withPol ( [useOpp?, 

gotoRoom(a-113) .deliverUrgentMail] , 
[gotoRoom(a-118) ,giveMail(gerhard)] ) ) ) . 

The outer policy is activated whenever the robot en- 
ters the hallway. It concurrently monitors whether 
the robot reaches a location near a door, whereat is 
checks whether the door is open or not. If A-113 
is detected to be open, the fluent useOpp is set true 
(by procudure checkDoor). The policy is deactivated 
when the robot leaves the hallway. 
The inner policy is activated as soon as useOpp gets 
true. It's purpose is to use the opportunity to enter 
A-113 as soon as possible. Figure 3 illustrates the 



projected trajectory, assuming that the door to A- 
113 is open. 

• A longer trajectory through all rooms. 

withPol (whenever (inHallway , 
[say (enterHW) , 
[say (enterHW) , 

tryAlK [whenever (nearDoor (a-110) , 

[checkDoor (a-110+121) .false?] )] , 
...]), 

[gotoRoom(a-114) ,say(a-114) , 

gotoRoom(a-113) , say (a-113) , 

gotoRoom(a-112) ,say(a-112) , 

gotoRoom(a-lll) ,say(a-lll) , 

gotoRoom(a-llO) , say (a-110) , 

gotoRoom(a-117) , say (a-117) , 

gotoRoom(a-118) , say (a-118) , 

gotoRoom(a-119) ,say(a-119) , 

gotoRoom(a-120) ,say(a-120) , 

gotoRoom(a-121) , say (a-121) 
]))))) 

Figure 4 shows the time it took to generate a projec- 
tion of the example plans using cc-Golog resp. xfrm, 
as well as the number of actions resp. events occur- 
ing in the projection. Both cc-Golog and xfrm run 
on the same machine (a Linux Pentium III Worksta- 
tion), under Allegro Common Lisp Trial Edition 5.0 
resp. Eclipse 4.2. As it turns out, cc-Golog appears 
to be faster by an order of magnitude than xfrm. We 
believe that cc-Golog owes this somewhat surprising ad- 
vantage to the fact that it lends itself to a simple imple- 
mentation with little overhead, while xfrm relies on the 
rather complex RPL-interpreter involving many thou- 
sand lines of Lisp code. 



Problem: 


cc-Golog 


XFRM 


Intro. Ex. 


0.4 s / 115 acts 




AIPS-98. Ex. 


0.5 s / 73 acts 


3.6 s / 106 evs 


Long Traj. 


3s/ 355 evs 


22.7 / 486 evs 



Figure 4: Runtime in seconds 



It also seems noteworthy that cc-Golog contents it- 
self with significantly less predicted relevant events (i.e. 
atomic actions) than xfrm. This results from the fact 
that cc-Golog only predicts an action if an action is actu- 
ally executed (unlike xfrm, which also projects events 
whose only purpose is to test if actual changes occur, 
like the "reschedule" events; see (Beetz & Grosskreutz 
1998)). Finally, and maybe most importantly, the cc- 
Golog implementation is firmly based on a logical speci- 
fication, while xfrm relies on the procedural semantics 
of the RPL interpreter. 

Conclusions 

In this paper we proposed an extension of the situation 
calculus which includes a model of continuous change 



due to Pinto and a novel approach to modeling the pas- 
sage of time using a special waitFor-action. We then 
considered cc-Golog, a deterministic variant of ConGolog 
which is based on the extended situation calculus. A 
key feature of the new language is the ability to have 
part of a program wait for an event like the battery 
voltage dropping dangerously low while other parts of 
the program run in parallel. Such mechanisms allow 
very natural formulations of robot controllers, in par- 
ticular, because there is no need to state explicitly in 
the program when actions should occur. In addition to 
the sound theoretical foundations on which cc-Golog is 
built, experimental results have shown a superior per- 
formance in computing projections when compared to 
the projection mechanism of the plan language RPL, 
whose expressive power has largely motivated the de- 
velopment of cc-Golog. 

However, much remains to be done. For one, sens- 
ing actions need to be properly integrated into this 
approach. Here we hope to benefit from existing ap- 
proaches in GOLOG and ConGolog (Lakemeyer 1999; 
de Giacomo & Levesque 1998). Also, uncertainty plays 
a central role in the robotics domain which should 
be reflected in a plan language as well. Based on 
foundational work within the situation calculus (Bac- 
chus, Halpern, & Levesque 1995) first preliminary re- 
sults have been obtained regarding an integration into 
ConGolog (Grosskreutz 1999; Grosskreutz & Lakemeyer 
2000). 

Finally, a few words are in order regarding the use of 
projections in cc-Golog. They should be understood as 
a way of assessing whether a program is executable in 
principle. The resulting execution trace of a projection 
is not intended as input to the execution mechanism of 
the robot. This is because the time point of a waitFor- 
condition like a low battery level is computed based 
on a model of the world which includes a model of the 
robot's energy consumption. In reality, of course, the 
robot should react to the actual battery level by period- 
ically reading its voltage meter. In the runtime system 
of RPL for an actual robot (Thrun et al. 1999) this link 
between waitFor-actions and basic sensors which are 
immediately accessible to the robot has been realized. 
One possibility to actually execute cc-Golog-programs 
on a robot would be to combine this idea of execut- 
ing waitFor's with an incremental interpreter along the 
lines of (de Giacomo & Levesque 1999). We leave this 
to future work. 
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